Max value that can be held in Real Variable

Mathias Mamsch - Tue Apr 20 19:34:42 EDT 2010
Hmmm ... I don't see what converting the 64 bit hexadecimal value 0xFFFFFFFFFFFFFFFF = 18446744073709551615 has to do with the maximum value a 64bit real variable can store. You can store much larger values in a 64bit real var:
{code}
real x = 1.342E27
print x
}

You are mixing up the integer and floating point representations of numbers. What you are talking about is a "precision" problem, not a maximum number problem. The number 18446744073709551615 cannot be represented exactly in floating point. You can get about 17 signigicant decimal digits from a 64 bit real number.

You find a lot of information about this problem on google. So this is not a DOORS problem, but a general floating point problem. Regards, Mathias

simon.gwilliam - Wed Apr 21 05:40:25 EDT 2010
Hi, I work with Zenyk who wrote the original post.

The full problem we're having is as follows:

Our dxl scripts is design to validate numbers to check that they can be held given the 'size(bits)' attribute value for that object.

For a 64-bit unsigned integer, we thought the valid values would be between the range 0 - 2^64. But we now understand that a real type is like a the double type in C, with 64 bits: 1 for sign, 11 for the exponent, and 52 for the mantissa. Its range is +/–1.7E308 with at least 15 digits of precision. But we can't use this range to validate the number that is input because although it might be within the range, it could be too precise and therefore impossible to hold in 64 bits.

IS there anyway of doing a check in dxl that a number can be held in 64 bits?

(btw, the reason we were using reals is that our test matter for these scripts has to include an invalid entry. While a real number simply 'rounds-up' the value, trying to define it as an integer results in an error)

I hope I'm making sense.

Simon

Mathias Mamsch - Wed Apr 21 07:33:03 EDT 2010
Other than real (64 bits) and integer (32 bits) there are no other number types in DXL. What I don't understand is, where you get these numbers from, that you want to check against this limit? Is that a string in a module, that you convert? And is this a decimal representation of that number? Is it a signed number?

If so, since you have no possibility to store that number in 'int' or in 'real' you can only operate on string. It should not be too hard to check a string decimal agains a certain limit, a length comparison combined with a string comparison in case of equal lengths or something like this.

Regards, Mathias

simon.gwilliam - Wed Apr 21 08:11:08 EDT 2010
Ok,

Our module defines the data held within a message. Each object represents a field within that message. An attribute of each object in our module contains a number. Each object has another attribute to define the type of this number (signed integer, floating, etc) Each object has another attribute which defines the number of bits that are assigned for this number (8, 16, 32 or 64 bits).

Our dxl scripts needs to check that the number itself is within the valid range for the number of bits specified and for the type of the number itself.

So we need to write some code which will define a valid range/set of numbers for an unsigned integer, a signed integer and a floating point number for each of the bit sizes.

Take the example of an unsigned integer that is to be held in 64 bits within this 'message' (module) that we are validating. How to we get dxl to check that this number is valid?

Mathias Mamsch - Wed Apr 21 09:50:00 EDT 2010

Hmm ... I experimented a little - its all awkward ... You could operate on strings and write your own numeric library which works on string (implement a string number division, etc.). Awkward.

Just checking against the maximum number is not so hard:
 

bool stringSmallerThanMaxInt(string s) {
         if (length s < length "18446744073709551615") return true
         if (length s > length "18446744073709551615") return false
         return s <= "18446744073709551615"
    } 
 
print stringSmallerThanMaxInt ("18446744073709551615")
print stringSmallerThanMaxInt ("18446744073709551617")
print stringSmallerThanMaxInt ("1234")
print stringSmallerThanMaxInt ("100000000000000000001")

But this solves only part of your problem. I checked the possibility to use a COM object to do the number crunching - no luck there. I guess this is the time, where you want to leave DXL and do the calculations in a language that supports 64bit data types. I would suggest using python.

Running something like this on the commandline will result in "False" beeing printed.

python -c "print 18446744073709551617<18446744073709551615"

You could also easily do hex conversions or any other number stuff using the python libraries.

python -c "print hex(18446744073709551617)"

Hope that gives you some ideas. Regards, Mathias

simon.gwilliam - Wed Apr 21 10:41:00 EDT 2010
Thanks,

Do you know how big the mantissa and exponent factors are in a 64 bit real or int value in dxl?

If it is the same as a double in c, as I've read, then it would be 52 bits for the mantissa. This means a maximum value from the mantissa of:

2^52 = 4503599627370496

So am I right in thinking that any number greater than this would have to have noughts on the end?

Mathias Mamsch - Wed Apr 21 11:13:16 EDT 2010
DXL uses (internally) the c++ double types, so should be exactly the same as in c++ (as if telelogic would have implemented their own floating point library).

Not any number greater than that would need to be rounded. You can take any number from 0-4503599627370496 and multiply it by any power of 2 (from -1023 to 1024 = 11 bits) and that number could be exactly be represented in a double. All other numbers will have rounding errors.

Regards,Mathias

simon.gwilliam - Wed Apr 21 11:38:34 EDT 2010
Thanks for all this help.

How then are 'int's held in dxl? i.e. how can you define valid integers for a 64 bit field?

simon.gwilliam - Wed Apr 21 05:40:25 EDT 2010
Hi, I work with Zenyk who wrote the original post.

The full problem we're having is as follows:

Our dxl scripts is design to validate numbers to check that they can be held given the 'size(bits)' attribute value for that object.

For a 64-bit unsigned integer, we thought the valid values would be between the range 0 - 2^64. But we now understand that a real type is like a the double type in C, with 64 bits: 1 for sign, 11 for the exponent, and 52 for the mantissa. Its range is +/–1.7E308 with at least 15 digits of precision. But we can't use this range to validate the number that is input because although it might be within the range, it could be too precise and therefore impossible to hold in 64 bits.

IS there anyway of doing a check in dxl that a number can be held in 64 bits?

(btw, the reason we were using reals is that our test matter for these scripts has to include an invalid entry. While a real number simply 'rounds-up' the value, trying to define it as an integer results in an error)

I hope I'm making sense.

Simon

llandale - Wed Apr 21 12:28:38 EDT 2010

Here are some random thoughts.

If the number is supposed to be an unsigned integer it must be composed of digits 0-9. Any leading zeros should be allowed but removed before parsing. It should be easy to check this parsed integer vis-a-vis the number of precision bits allowed.

Signed integers can be preceded with a minus sign, but otherwise must be valid unsigned integers, with half the range.

If its a real number it can be preceded with a minus sign, but otherwise must be composed of Whole-number part digits 0-9, a period, and Decimal-number part digits 0-9. Decimal part trailing zeros should be removed unless that part is zero. Whole number leading zeros should be removed, unless the entire whole number is zero. Now the tricky part. Take the Whole number part and concatenate the Decimal number part (without the period), and remove all leading and trailing zeros, then concatenate the optional minus sign, we must end up with a valid signed integer; whose precision is ... I don't know. Having said that, the number of leading and trailing zeros that you remove is a factor, but I don't understand how to calculate that.

In my ignorance: I don't know what to think about the previous post about Mantisa being 52 bits, since real numbers for me routinely display 17 decimal digits, which is closer to 63 bit precision. Even this number seems valid: 2582249878086908600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.000000 (about=2e400)

It appears integers have 32 bits of precision, as evidenced by this DXL:

int     i
int     PowPos = 0,
        PowNeg = 0
 
for (i=0; i<65; i++)
{  print "\t** " i ""
   PowPos = (PowPos*2)+1
   PowNeg = (PowNeg*2)-1
 
   print" [" PowPos "] [" PowNeg "]"
}

which produces this result:

** 0 [1] [-1]    ** 1 [3] [-3]  ** 2 [7] [-7]   ** 3 [15] [-15] ** 4 [31] [-31] ** 5 [63] [-63] ** 6 [127] [-127]       ** 7 [255] [-255]       ** 8 [511] [-511]       ** 9 [1023] [-1023]     ** 10 [2047] [-2047]    ** 11 [4095] [-4095]    ** 12 [8191] [-8191]    ** 13 [16383] [-16383]  ** 14 [32767] [-32767]  ** 15 [65535] [-65535]  ** 16 [131071] [-131071]        ** 17 [262143] [-262143]        ** 18 [524287] [-524287]        ** 19 [1048575] [-1048575]      ** 20 [2097151] [-2097151]      ** 21 [4194303] [-4194303]      ** 22 [8388607] [-8388607]      ** 23 [16777215] [-16777215]    ** 24 [33554431] [-33554431]    ** 25 [67108863] [-67108863]    ** 26 [134217727] [-134217727]  ** 27 [268435455] [-268435455]  ** 28 [536870911] [-536870911]  ** 29 [1073741823] [-1073741823]        ** 30 [2147483647] [-2147483647]        ** 31 [-1] [1]  ** 32 [-1] [1]  ** 33 [-1] [1]  ** 34 [-1] [1]  ** 35 [-1] [1]  ** 36 [-1] [1]  ** 37 [-1] [1]  ** 38 [-1] [1]  ** 39 [-1] [1]  ** 40 [-1] [1]  ** 41 [-1] [1]  ** 42 [-1] [1]  ** 43 [-1] [1]  ** 44 [-1] [1]  ** 45 [-1] [1]  ** 46 [-1] [1]  ** 47 [-1] [1]  ** 48 [-1] [1]  ** 49 [-1] [1]  ** 50 [-1] [1]  ** 51 [-1] [1]  ** 52 [-1] [1]  ** 53 [-1] [1]  ** 54 [-1] [1]  ** 55 [-1] [1]  ** 56 [-1] [1]  ** 57 [-1] [1]  ** 58 [-1] [1]  ** 59 [-1] [1]  ** 60 [-1] [1]  ** 61 [-1] [1]  ** 62 [-1] [1]  ** 63 [-1] [1]  ** 64 [-1] [1]

-Louie

Mathias Mamsch - Wed Apr 21 12:34:58 EDT 2010
You just made this a really "wide" topic :-) ... Why not insert some "\n" the next time.

Mathias Mamsch - Wed Apr 21 12:09:53 EDT 2010
Its just the the int - type in c++ (32 bit). DXL has no LONG type with 64 bits. You can define your own 64 bit integer type, but for the initialization you would have to code a stringToLongInt function.

Regards, Mathias

simon.gwilliam - Thu Apr 22 04:31:41 EDT 2010
So the valid range of numbers that can be held as an int is simply 2^31 (1 sign bit i presume?)? And there is no exponent factor?

Sorry to bring this down to basics, but I don't have much S/W experience, least of all with C/C++

Mathias Mamsch - Fri Apr 23 14:10:20 EDT 2010
No there is no exponent in an integer. The mantissa, exponent, sign stuff does only make sense for floating points (since you can multiply them very easily, which is a costly operation otherwise).

Regards, Mathias

simon.gwilliam - Mon Apr 26 05:41:39 EDT 2010
Ok, thanks.

I have been able to implement the solution using string comparison for the integer types.

But for floating-point type, how do I get a dxl script to determine whether a number can be held, to full precision, as a 64-bit floating point double precision number, or whether it would need to be rounded up/down?

If anyone can find a solution to this, I would be very grateful indeed.

So far we have been thinking about attempting to split the number into potential mantissa and exponent, and then testing these seperately to determine that they can be held within the 52 bit and 11 bit parts respectively.

Regards,

Simon

simon.gwilliam - Mon Apr 26 05:41:39 EDT 2010
Ok, thanks.

I have been able to implement the solution using string comparison for the integer types.

But for floating-point type, how do I get a dxl script to determine whether a number can be held, to full precision, as a 64-bit floating point double precision number, or whether it would need to be rounded up/down?

If anyone can find a solution to this, I would be very grateful indeed.

So far we have been thinking about attempting to split the number into potential mantissa and exponent, and then testing these seperately to determine that they can be held within the 52 bit and 11 bit parts respectively.

Regards,

Simon

pCarsten - Mon Apr 26 11:25:24 EDT 2010
If the number, end-to-end is 16 digits or less, it can be stored w/ full precision.

I.e. 123456789012345.6 will be stored as expected.
So will 1.234567890123456.

This is for storage only. If you try to do any kind of math (e.g. adding the two numbers together), the result will not be what you expect.

(I'm assuming that both the C/C++ compiler and hardware used for DOORS adhere to the IEEE 754 standard).

simon.gwilliam - Mon Apr 26 11:32:04 EDT 2010
So far as I understand, yes.

It isn't as simple as that though is it? (genuine question)

I mean, trying to get my head around double precision via wikipedia. It states that the largest number you can represent is:

1.79769 × 10^308 (roughly)

Now when written out in full, this is more than 16 digits, so are you saying that only non-zero digits count?

Also, it isn't possible to hold 1.8 x 10^308 is it? That has less than 16 significant figures.

So how can you literaly define the numbers that can possibly be held with double precision?

pCarsten - Mon Apr 26 11:57:57 EDT 2010
The first 16 digits that are seen are stored precisely. Anything after that is more or less random.

1.234567890123456 is stored precisely as 1.234567890123456, and then some more decimals to the right, which you can't expect to be precise.

123456789012345.6 is stored precisely as 123456789012345.6, and then some more decimals to the right, which you can't expect to be precise.

If you try to add 123456789012345.6 and 1.234567890123456, you end up with something like 123456789012346 - plus something to the right, which you can't expect to be precise.

This is about as well as I can explain it. The best explanation I've ever seen on IEEE 754 is one of the appendices of Andrew Tannenbaum’s "Structured Computer Organization". You might want to get your hands on that.

simon.gwilliam - Mon Apr 26 12:02:44 EDT 2010
I understand, but how do I implement a check in dxl. And what if the number is in index form with a huge power.

Surely with an 11 bit exponent you could produce the number:

0.00000000000000000000000000000000000000000001 or something like that. Can this number be stored as a double precision? There are more than 16 digits, but only 1 number.